1. Field of the Invention
The present invention relates generally to a method and apparatus for providing a multicasting service in a CDMA (Code Division Multiple Access) system, and in particular, to a method and apparatus for supporting multicasting in a CDMA system providing a high-speed packet data service such as CDMA 1xEV-DO (Evolution-Data Only) and CDMA 1xEV-DV (Data and Voice).
2. Description of the Related Art
The existing IS-95A, IS-95B, and IS-95C systems are inefficient for data communications because they focus on voice service, thereby restricting data service. To solve this problem, two systems have been proposed by Qualcomm: the first is HDR (High Data Rate) i.e., 1xEV-DO, which is a data only technology, and the second is 1xEV-DV, which carries both data and voice. These two systems are ready for commercial deployment.
These high-speed data transmission technologies achieve Mbps-level data rates as defined in IMT-2000 (International Mobile Telecommunication-2000). Thus, real-time transmission of moving pictures and a multimedia download service are possible through a terminal like a video phone.
In general, data packets are unicast, broadcast, or multicast over a wired network from the perspective of transmitters and receivers. Unicast is a one-to-one transmission. For example, all typical Internet application programs are unicast. Broadcast is a one-to-many transmission in a subnetwork. Multicast is a data transmission from one or more transmitters to two or more receivers, as can be found in Internet video conferencing.
In a mobile communication system, especially CDMA 1xEV-DO and 1xEV-DV, data packets are only unicast or broadcast. As done over a wired network, unicast transmission is carried out from a base station (BS) to each individual mobile station (MS) and multicast transmission refers to simultaneous transmission of the same information from the BS to all MSs within the service area of the BS.
The configuration of a typical mobile communication system that unicasts or broadcasts data will be described with reference to FIGS. 1 to 11.
FIG. 1 illustrates a network configuration for the typical mobile communication system such as 1xEV-DO. Referring to FIG. 1, an MS 100 exchanges voice or data with BTSs (Base Transceiver Systems) 200 including BTS-a and BTS-b through a radio interface. A BSC (Base Station Controller) 300 controls the BTSs 200. In a CDMA 1xEV-DO system, an AT (Access Terminal) is equivalent to an MS and an AN (Access Network) is equivalent to both a BSC and a BTS. Thus, it can be appreciated that the both the MS and AN are used in the same sense and the BSC and the BTS are used in the same sense as the AN herein. The BSC 300 communicates for call connection with the Internet, PSTN (Public Switched Telephone Network), and PSDN (Public Switched Data Network) via a GW (GateWay)/MSC (Mobile Switching Center) 400. “GW” 400 is a logical name, as the entity is usually referred to as a PDSN (Packet Data Service Node), AGW (Access GateWay), or MGW (Media GateWay).
FIG. 2 is a block diagram of the BTS 200 illustrated in FIG. 1. Referring to FIG. 2, the BTS 200 is connected to the BSC 300 via a duplexing network interface 201 such as an NIC (Network Interface Card) or LIC (Line Interface Card). The network interface 201 is connected to a BTS switch (or router) 203. The network interface 201 interfaces data between the BTS 200 and the BSC 300. The BTS switch 203 switches received data under the control of a BTS controller 205. Thus, the BTS switch 203 is comprised of an intra-BTS switch (router).
The BTS controller 205 manages resources in the BTS 200. The BTS 200 further includes a plurality of channel cards 207; each of which is assigned to one user. Each channel card 207 controls traffic transmission between the BTS 200 and an MS in cooperation with a traffic controller 309 of the BSC 300. Specifically, the channel card 207 processes data received from an RF (Radio Frequency) module 209 and feeds the processed data to the BTS switch 203. The channel card 207 also processes data received from the BTS switch 203 and feeds the processed data to the RF module 209. For data transmission between the BTS 200 and the MS on radio channels, the RF module 209 upconverts the frequency of a signal received from each channel card 207 and transmits it in the air, or it downconverts an RF signal in a predetermined frequency band received from each MS and outputs it to a corresponding channel card 207.
An RF-scheduler processor 211, connected to the BTS switch 203, is used for efficient use of resources. It can be integrated into a channel card 207 or implemented as a separate processor.
FIG. 3 is a block diagram of the BSC 300 illustrated in FIG. 1. Referring to FIG. 3, the BSC 300 includes a duplexing network interface 301 connected to the GW/MSC 400, for interfacing data between the BSC 300 and the GW/MSC 400. It also includes a network interface 303 connected to the BTS 200, for interfacing data between the BSC 300 and the BTS 200. The network interfaces 301 and 303 are connected to a BSC switch (router) 305.
The BSC switch 305 takes charge of data routing and switching within the BSC 300. The BSC switch 305 transmits/receives data bi-directionally between the network interfaces 301 and 303. In the presence of data to be transmitted to a BSC controller 307, the BSC switch 305 switches the data to the BSC controller 307. In the presence of data to be transmitted to the traffic controller 307, the BSC switch 305 switches the data to the traffic controller 309.
The BSC controller 307 provides overall control to the BSC 300 and manages BSC 300 resources and part of BTS 200 resources.
The traffic controller 309 has an SDU/RLP (Selection and Distribution Unit/Radio Link Protocol) processor for traffic transmission/reception with a plurality of MSs. The SDU/RLP processor transmits traffic to a plurality of BTSs and combines data originated from the same MS as received from the BTSs. Although the SDU/RLP processor can be integrated into the GW 400, it is assumed herein that the SDU/RLP processor is positioned in the BSC 300. The SDU/RLP processor converts packet traffic received from the GW 400 to an error control protocol frame, prior to transmission to the BTSs 200.
FIG. 4 is a block diagram illustrating certain component parts of the BTS 200 and the BSC 300. Specifically, FIG. 4 illustrates an AN, which supports unicast transmission. The conventional AN which supports unicast transmission is comprised of a call control processor 401 and an SDU/RLP processor 405 in the BSC 300, and a call control processor 403, a unicast MAC (Medium Access Control) processor 407, and a MODEM 409 in the BTS 200. In FIG. 4, a solid line indicates a traffic path and a dotted line indicates a control information path.
Referring to FIG. 4, the BSC call control processor 401 and the BTS call control processor 403 perform call processing. They correspond to the BSC controller 307 and the BTS controller 205, respectively. Yet, the BSC call control processor 401 and the BTS call control processor 403 can be implemented in dedicated hardware. These call control processors establish a call and control the SDU/RLP processor 405 and the unicast MAC processor 407 to transmit forward traffic.
The unicast MAC processor 407 manages resources including MAC indexes and UATIs (Unicast Access Terminal Identifiers) and assigns them to MSs. The unicast MAC processor 407 delivers traffic received from the higher-layer SDU/RLP processor 405 together with a MAC index identifying a particular AT to the MODEM 409, and delivers traffic received from the MODEM 409 to the SDU/RLP processor 405.
The MODEM 409 is a device that supports a radio physical layer. It usually corresponds to the channel cards 207 in the BTS 200. The MODEM 409 encodes traffic received from the unicast MAC processor 407, spreads the received MAC index with a corresponding Walsh code, and modulates the traffic and MAC index, prior to transmission on a radio channel to the AT.
Thus the AN, but more particularly, the unicast MAC processor 407, manages AT-specific MAC indexes for unicast transmission of data to ATs. The MAC indexes indicate which Walsh code numbers (among Walsh codes #0 to #63) have been assigned to an AT, thus defining a MAC channel. Each AT is assigned to a traffic channel by receiving a MAC index specific to the AT from the AN. The AN assigns the traffic channel to the AT using the Walsh code corresponding to the MAC index. The AN then transmits data to the AT on the traffic channel, allowing only the AT to receive the data.
FIG. 5 specifies a procedure for assigning a traffic channel (i.e. MAC index) from the AN to the AT, for a unicast data transmission. The traffic channel assignment procedure is triggered as the AT receives a Page message from the AN, or requests a call setup to the AN, for call origination. It can also be performed periodically or when the AT, moving to a different service area, transmits a routing update (RouteUpdate) message to the AN to update its location information. The traffic channel assignment procedure follows a session setup procedure in which a UATI is assigned to the AT. The session setup procedure negotiates a protocol for communication between the AT and the AN when the AT is power-on. The UATI is a temporary identifier indicating the address of the AT being a data destination, which the AN assigns to the AT when setting up a session for the AT. A UATI assignment procedure is specified in 3GPP2 A.S0007-0 Version 2.0, Inter-Operability Specification (IOS) for High Rate Packet Data (HRPD) Access Network Interfaces 7.
Referring to FIG. 5, the AN transmits a Page message to the AT on a control channel (CC) and the AT reads the Page message with its UATI set as a destination address in the CC message in step 501. In step 503, the AT, which has received the Page message or intends to originate a call, transmits a ConnectionRequest message to the AN on an access channel (AC), requesting assignment of a traffic channel for a call connection. The ConnectionRequest message is loaded on the AC with a UATI-based long code mask (LCM), or the AT can transmit a RouteUpdate message to the AN, as described above.
In step 505, the AN transmits an AccessChannel ACK (ACAck) to the AT, notifying normal reception of the ConnectionRequest/RouteUpdate message. The AN then assigns a traffic channel for unicast transmission to the AT by transmitting a TrafficChannelAssignment message on the CC with the UATI of the AT set as a message destination in step 507. The traffic channel assignment is equivalent to transmission of a MAC index, that is, assignment of a Walsh code to the AT. After receiving the MAC index from the AN by the TraffcChannelAssignment message, the AT can identify its data transmitted on a traffic channel with the Walsh code corresponding to the MAC index from the AN.
The AT transmits null data to the AN on a reverse traffic channel (RTC) which is long code masked according to its UATI in step 509. The AN transmits to the AT an RTCAck message with its UATI on the CC or a forward traffic channel (FTC), notifying normal reception of the RTC in step 511. In step 513, the AT transmits a TrafficChannelComplete message to the AN on an RTC which is long code masked according to its UATI, notifying successful completion of the traffic channel assignment.
FIG. 6 illustrates an example of radio channel information that the AN manages when it unicasts data to the AT using the MAC index assigned to the AT. With reference to FIGS. 6 to 11, MAC index-based unicast transmission will be described in detail below.
First, a description will be made of forward unicast transmission referring to FIGS. 6 and 7. FIG. 7 conceptually illustrates forward transmission from the AN to the AT.
Unicast forward data is comprised of a preamble, an FTC packet, and reverse power control (RPC) bits. The preamble is usually all 0s, providing information such as timing to a receiver before reception of actual data. The traffic channel packet is traffic information delivered to the receiver. An RPC channel is a sub-channel of a MAC channel. The RPC bits on the RPC channel are used for power control of an RTC.
Referring to FIG. 7, a preamble 701 is covered with a 32 symbol bi-orthogonal Walsh code according to a MAC index assigned to a destination AT. A traffic channel packet 703 is spread with Walsh codes indicated by the MAC index prior to transmission to the AT. RPC bits 705 are also covered with a Walsh code according to the MAC index.
FIGS. 9, 10 and 11 are block diagrams of respective components for processing the traffic channel data, preamble, and RPC bits prior to unicast transmission.
Referring to FIG. 9, an encoder 901 encodes an FTC packet and outputs a code sequence including a plurality of bit streams. The code sequence is scrambled with a scrambling code generated from a scrambler 903. A channel interleaver 905 interleaves the scrambled sequence. A modulator 907 modulates the interleaved sequence in a predetermined modulation method. A puncturer 909 punctures the modulation symbols to achieve a desired data rate and a symbol demultiplexer (DEMUX) 911 demultiplexes the punctured I and Q data streams into 16 parallel I and Q data sets. A Walsh coverer 913 multiplies each of the data sets by one of 16 Walsh covers corresponding to a MAC index assigned to a destination AT. Thus, the Walsh-covered traffic packet is output on 16 Walsh channels 915. A Walsh chip level summer 917 adds all the I and Q signals of the Walsh channels 915 together at the chip level as the final signals.
Referring to FIG. 10, a signal point mapper 1001 maps 0s and 1s of a preamble signal to +1s and −1s, respectively. A Walsh spreader 1003 then spreads the preamble signal with a Walsh code according to the MAC index. After being repeated in a sequence repeater 1005, the spread preamble signal is transmitted in time division multiplexing (TDM) to the AT.
Referring to FIG. 11, MAC channel RPC bits are spread with a Walsh code according to the MAC index after processing in a signal point mapper 1101 and a reverse channel gain controller 1103.
A reverse link transmission will now be described with reference to FIGS. 6 and 8. An AN distinguishes ATs by their UATIs. Each AT transmits data long-code-masked according to UATI to the AN so that the AN identifies the AT by the UATI.
As illustrated in FIG. 6, the AN transmits system information to all ATs within its service area on a CCS that the ATs can identify. The CC uses a broadcast MAC (BMAC) index and a recipient address for a system parameter message delivered on the CC is defined with a broadcast access terminal identifier (BATI). For example, the ATs receive a message with BATI(0,0) among messages delivered on the CC with BMAC Index 0.
Thus far, unicast data transmission and broadcast data transmission have been described in the context of the traditional 1xEV-DV system supporting high-speed data transmission.
If the same data is to be transmitted to a plurality of ATs, the unicast transmission scheme requires multiple transmissions of a data packet to the ATs, thereby decreasing network efficiency. As the number of the ATs increases, this problem becomes serious.
Alternatively, broadcast transmission of the data packet leads to unnecessary delivery of the data packet to unintended ATs. Therefore, there is a need for minimizing transmission redundancy-caused waste of network resources by introducing multicast transmission as found in a conversational Internet function such as video conferencing.